Skip to main content

Browser Background

The use of a browser to connect to, administer, and configure endpoint devices (including routers) is an already established practice. Today most connections between browsers and endpoints are unencrypted because the mechanisms which enable secure communication are hard to use. The challenge we are trying to address is how to enable secure communication that is easy to use.

The solutions to this problem come in two major classes:

  1. No browser changes: These solutions use the existing DNS and CA infrastructure and their well-understood security semantics to address our problem requirements without any changes to existing browser behaviour.
  2. Customised browser: more substantive innovation in addressing methods and the negotiation of trust relationships that will inevitably require browser changes. A customised browser is either a fork of a regular mainstream browser or a dedicated tool build from the ground up.

There is an alternative to using the browser for administration that requires device manufacturers to develop and maintain custom applications. A user would need to add an application to their smartphone for every manufacturer of devices that they use. We feel a universal browser-based solution is much more attractive.

See also [reasons for not using bespoke IoT management applications](/suib/Problem Statement/SUIB-whitepaper#solution-3-use-an-app)

We recognise that any solution that requires a significant change to existing browser behaviours will have to demonstrate its benefits via a dedicated custom browser before it could be adopted. Because browser behaviour is impacted, and interoperability is essential, coordination through the relevant standards body, in this case the CA/Browser Forum, would be required.

No browser changes​

Solutions which require no change to existing browser behaviour are desirable because these have minimal impact on the end user.

The browser does not enable the user to easily distinguish between local connections and Internet connections and to do so would require UI changes. The distinction between local and Internet connections is potentially significant to the security semantics of IoT end point devices.

This means any solution which has no change to the browser will have some dependency on DNS resolution, at least in the bootstrap binding phase.

This has two knock on effects:

  1. Internet access is always necessary for device binding.
  2. It places an infrastructure requirement (DNS servers and CA infrastructure) on the manufacturer, or other stakeholders taking responsibility for device setup.

Changing browser behaviour​

An alternative and/or complementary solution could be the development of a dedicated IoT browser, which would use dedicated IoT certificates. This would leave the Internet certificates unaffected and would introduce a similar certificate processing semantics for the IoT.

Vendors often offer mobile apps because they implement their own certificate validation independent of the WebPKI/CABForum CAs. This approach requires an application for every device or service. A dedicated IoT application could bundle these services and simplify the user experience. However, concerning the dedicated application:

  • There is a significant issue regarding ongoing support.

  • It requires users to adopt a new class of browser and users tend to be reluctant to new ways of working.

  • It needs to be designed from the ground up.

There is the possibility that a dedicated application is not needed. A special profile of an existing browser, perhaps with some specific plugins, may suffice.

Advantages of a specialised browser​

An enhanced browser provides us with the following opportunities:

  1. We can differentiate the user experience when browsing local resources and global resources. This is meaningful information to present to the user from a security perspective.
  2. We can implement additional name resolution methods, which help with the local addressing problem.
  3. We can implement new methods to negotiate the secure TLS session.

On point 3 in particular, we could envisage a scenario where IoT specific CAs were created, with a suite of RootCAs, which are separate, but complementary to, the suite of root CAs used in browser at the moment, and could implement a different mechanism of validation, which does not exclude "internal names" and "private use".

In terms of specific strategies for changing browser behaviour, this could come in a number of flavours:

  • Create a local/IoT only browser.
  • Create a browser that is capable of both Internet browsing and local browsing.
  • The browser could be released as proprietary products conforming to a common specification.
  • The browser could be released as an open-source tool.
  • The CA/Browser forum could be lobbied to accommodate the broader specifications that include local resources.